#LyX 2.0 created this file. For more info see http://www.lyx.org/ \lyxformat 413 \begin_document \begin_header \textclass article \use_default_options true \maintain_unincluded_children false \language english \language_package default \inputencoding auto \fontencoding global \font_roman default \font_sans default \font_typewriter default \font_default_family default \use_non_tex_fonts false \font_sc false \font_osf false \font_sf_scale 100 \font_tt_scale 100 \graphics default \default_output_format default \output_sync 0 \bibtex_command default \index_command default \paperfontsize default \spacing single \use_hyperref false \papersize default \use_geometry false \use_amsmath 1 \use_esint 1 \use_mhchem 1 \use_mathdots 1 \cite_engine basic \use_bibtopic false \use_indices false \paperorientation portrait \suppress_date false \use_refstyle 1 \index Index \shortcut idx \color #008000 \end_index \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \paragraph_indentation default \quotes_language english \papercolumns 1 \papersides 1 \paperpagestyle default \tracking_changes false \output_changes false \html_math_output 0 \html_css_as_file 0 \html_be_strict false \end_header \begin_body \begin_layout Title Software Requirements Specification for Pontarius XMPP 0.1 (Third Draft) \end_layout \begin_layout Author The Pontarius Project \end_layout \begin_layout Date 27th of July 2011 \end_layout \begin_layout Standard \begin_inset CommandInset toc LatexCommand tableofcontents \end_inset \end_layout \begin_layout Section Introduction \end_layout \begin_layout Subsection Purpose \end_layout \begin_layout Standard The goal of this document is to clarify---for Pontarius \begin_inset Foot status open \begin_layout Plain Layout For more information about the Pontarius project, see http://www.pontarius.org/. \end_layout \end_inset developers, the XMPP community, and to some extent the Haskell community---what we are implementing. We hope that it will help us in the Pontarius project to keep track of functionality and requirements, provide a basis for scheduling, and help us with our validation and verification processes. \end_layout \begin_layout Subsection Scope \end_layout \begin_layout Standard Pontarius XMPP 0.1 will implement the client capabilities of RFC 6120: XMPP: Core and the depending specifications, such as RFC 6122: XMPP: Address Format, RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2, RFC 4422: Simple Authentication and Security Layer (SASL), RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, and Extensible Markup Language (XML) 1.0, among others. \end_layout \begin_layout Standard Support for common extensions such as Instant Messaging, Data Forms, Service Discovery, etc. will \emph on not \emph default be included in the 0.1 version, but will be added in later ( \begin_inset Quotes eld \end_inset 0.x \begin_inset Quotes erd \end_inset ) versions. Server components and XMPP server capabilities could also be added later. \end_layout \begin_layout Standard While it is the goal of the Pontarius project to develop secure and privacy-awar e \begin_inset Quotes eld \end_inset personal cloud \begin_inset Quotes erd \end_inset solutions on top of Pontarius XMPP, we want Pontarius XMPP to be a general-purp ose---and the de facto---XMPP library for Haskell. It should be correct and efficient to work in. \end_layout \begin_layout Standard We will not repeat the specifics of the requirements from the RFC 6120: XMPP Core specification and its depending specifications in this document unless we see any special reason to. \end_layout \begin_layout Subsection Legal notice \end_layout \begin_layout Standard Pontarius XMPP is a free and open source software project. \begin_inset Quotes eld \end_inset The Pontarius project \begin_inset Quotes erd \end_inset is not a legal entity, but is like a synonym for Jon Kristensen. Jon Kristensen does DOES NOT TAKE ANY RESPONSIBILITY OR OFFER ANY GUARANTEES in regards to the software, its requirements or this document. Furthermore, the software is provided WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. \end_layout \begin_layout Subsection Definitions, acronyms, and abbrevations \end_layout \begin_layout Description JID JabberID: An address for XMPP entities \end_layout \begin_layout Description Pontarius A free and open source software project that aims to produce XMPP-base d, uncentralized, and privacy-aware software solutions \end_layout \begin_layout Description PX01 Pontarius XMPP 0.1 \end_layout \begin_layout Description REQ Requirement \end_layout \begin_layout Description RFC Request for Comments: A memorandum published by the Internet Engineering Task Force; some of these, including XMPP: Core and XMPP: Address Format, are published as Internet standards \end_layout \begin_layout Description TCP Transmission Control Protocol: A reliable network transport protocol \end_layout \begin_layout Description TLS Transport Layer Security: A secure network protocol, a successor to Secure Sockets Layer (SSL) \end_layout \begin_layout Description XMPP Extendable Messaging and Presence Protocol: An uncentralized, open, and near-real-time presence and messaging protocol \end_layout \begin_layout Subsection References \end_layout \begin_layout Itemize Extensible Messaging and Presence Protocol (XMPP): Core, RFC 6120, March 2011, Internet Engineering Task Force (see also its depending specifications) \end_layout \begin_layout Subsection Overview \end_layout \begin_layout Standard The second section provides an overall description of the requirements of PX01, going through the features in a non-strict fashion, talking shortly about the product functions, as well as some constraints and assumptions. \end_layout \begin_layout Standard The third section simply lists the requirements, categorized by external interfaces, functions, performance requirements, design constraints, and software system (quality) attributes. \end_layout \begin_layout Section Overall Description \end_layout \begin_layout Subsection Product perspective \end_layout \begin_layout Standard PX01 will be used by XMPP clients to manage presence and messaging in a uncentralized near-real-time environments. For this first milestone of the library, we have chosen to implement only the XMPP: Core specification, and only the client capabilities of it. The reason for this is that we want to get the library out quickly, and want to have the core functionality of the library particularly well tested. The X in XMPP stands for extendable, and Pontarius XMPP must be flexible in regards for extensions, such as RFCs and XEPs; we might end up implementing hundreds of them. This is one of the most important quality attribute of the software. \end_layout \begin_layout Standard PX01 is designed to be used with Haskell. \end_layout \begin_layout Standard PX01 must work on GNU/Linux, the main Free Software operating system. However, due to the platform support and high-level nature of Haskell, running it on other common operating systems is likely to work as well. \end_layout \begin_layout Standard PX01 must work with (at least) the (estimated) most popular free and open source software XMPP server that works with the specifics of our implementation (such as SCRAM). \end_layout \begin_layout Standard PX01 depends on the below (free and open source software) Haskell packages. I have omitted specification number [...]. I have also omitted the source, as they are all available on Hackage. \end_layout \begin_layout Standard \begin_inset space \space{} \end_inset \end_layout \begin_layout Standard \begin_inset Tabular \begin_inset Text \begin_layout Plain Layout Name (Mnemonic) \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout Version Number \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout Purpose \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout base \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout base64-string \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout binary \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout bytestring \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout containers \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout crypto-api \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout enumerator \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout hslogger \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout network \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout pureMD5 \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout QuickCheck \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout random \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout regex-posix \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout text \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout tls \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout 0.4.1 \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout transformers \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout utf8-string \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout xml-enumerator \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout xml-types \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \begin_inset Text \begin_layout Plain Layout N/A \end_layout \end_inset \end_inset \end_layout \begin_layout Standard \begin_inset space \space{} \end_inset \end_layout \begin_layout Standard Every PX01 client will open up at most one TCP port on the system. PX01 in itself does not write anything to the file system storage of the operating system, with the exception of the optional logging facility, disabled by default, which may be configured to write to disk. \end_layout \begin_layout Standard We will utilize \emph on at least \emph default Transport Layer Security to help protect clients using the library from attacks. PX01 will not provide any spam protection. \end_layout \begin_layout Standard As we expect a very limited amount of concurrent XMPP clients, and a (relatively ) limited actitivity over XMPP streams--even when they are being fully active--w e are not specifying any detailed memory or (process) performance requirements for PX01. However, we will stress test the library. \end_layout \begin_layout Standard We see no hardware or user interfaces to take into account. \end_layout \begin_layout Subsection Product functions \end_layout \begin_layout Standard PX01 implements XMPP: Core and allow clients to do roughly the following: Open a TCP connection to a server, exchange XML information with the server to configure the (XML) stream, handle stream errors and encoding issues, have the connection secured by TLS, authenticate using a SASL mechanism and binding a resource to the stream, as well as sending and receiving so-called XMPP stanzas, certain \begin_inset Quotes eld \end_inset top level \begin_inset Quotes erd \end_inset XML elements in the stream for communicating messages and presence. \end_layout \begin_layout Subsection User characteristics \end_layout \begin_layout Standard We expect developers using PX01 to understand the XMPP: Core specification (and its depending specifications), Haskell, and monads, including the StateT monad transformer. \end_layout \begin_layout Subsection Constraints \end_layout \begin_layout Standard In addition to the requirements in XMPP: Core, XMPP applications should be reliable in that they should be able to be online (active or inactive) for a very long period of time, without problems of memory leaks, unnecessary CPU usage, or similar, arising. \end_layout \begin_layout Subsubsection Assumptions and dependencies \end_layout \begin_layout Standard We assume that the Glasgow Haskell Compiler (GHC) is available on the system where PX01 applications are built. \end_layout \begin_layout Section Specific requirements \end_layout \begin_layout Subsection External interfaces \end_layout \begin_layout Standard The software is accessible from Haskell and may be configured to do logging. \end_layout \begin_layout Description REQ-1 The system shall be importable and fully functional from Haskell through a full import of the Network.XMPP namespace. \end_layout \begin_layout Description REQ-2 The system shall be able to log information through arbitrary and flexible log handlers. \end_layout \begin_layout Description REQ-3 The system shall run under GNU/Linux. \end_layout \begin_layout Description REQ-4 The system shall work against (at least) the (estimated) most popular free and open source software XMPP server supporting the features that we require (such as SCRAM). \end_layout \begin_layout Subsection Functions \end_layout \begin_layout Standard If an error arises due to a bug in the software, the system shall throw a runtime exception and the process should exit. If an \begin_inset Quotes eld \end_inset acceptable \begin_inset Quotes erd \end_inset exception is possible to arise, such as the XMPP server times out, then the related functions should reflect that by being able to return values such as Nothing or null. This allows the XMPP clients to take the appropriate actions. \end_layout \begin_layout Description REQ-5 The system shall be validating input from all functions exposed through any of the system's APIs. \end_layout \begin_layout Description REQ-6 Each incoming stanza should move through a stack of (client) handlers, where each handler may block the stanza from being delivered to handlers further up in the stack. The exceptions to this rule is stanza errors and IQ result stanzas, which may be delivered directly to a callback provided when generating the stanza (and possibly surpressed there). \end_layout \begin_layout Standard Rationale: We have so far found it useful to stack XMPP client handlers on top of each other, letting them all manage their particular responsibilities and surpress their messages to handlers further up the stack. \end_layout \begin_layout Description REQ-7 When the client is disconnected, a \begin_inset Quotes eld \end_inset disconnect event \begin_inset Quotes erd \end_inset is generated in a way similar to in REQ-5. It is moved through the stack handlers; however, these events move down the stacks completely and can't be surpressed. The same thing applies for incoming stream errors, which can either be recoverable or unrecoverable. (?) \end_layout \begin_layout Standard Rationale: We want the handlers to all do the appropriate clean-up activities. \end_layout \begin_layout Description REQ-8 The API shall allow for opening a stream to a given IP or host name on a given port, returning either a success value or the reason for failing. \end_layout \begin_layout Description REQ-9 The API shall allow for securing an opened stream with TLS, returning either a success value or the reason for failing. \end_layout \begin_layout Description REQ-10 The API shall allow for authenticating an opened (possibly TLS secured) stream, returning either a success value of the reason for failing. If the credentials were wrong, the system shall allow the client to make as many retries as allowed by the server, without restarting the stream. \end_layout \begin_layout Description REQ-11 The API shall allow for perform resource binding on an authenticated stream, either by trying to set a specific resource, or have the server generate one. \end_layout \begin_layout Standard Rationale: Even though most clients wants to do REQ-8, REQ-9, REQ-10, and REQ-11 in one action, some uses of XMPP (such as In-Band Registration) demands more flexibility. \end_layout \begin_layout Description REQ-12 The API shall provide a convenience function for opening a stream, securing the stream with TLS, authenticating an XMPP account, and perform resource binding in one function call, returning either a success value or the reason for failing. \end_layout \begin_layout Standard Rationale: This makes the library easier and more efficient to use for most uses cases. \end_layout \begin_layout Description REQ-13 The API shall provide the possibility for clients to close the stream. \end_layout \begin_layout Description REQ-14 The API shall provide the possibility for clients to send stream errors. \end_layout \begin_layout Description REQ-15 The API shall allow a convenient way for \begin_inset Quotes eld \end_inset standard disconnect \begin_inset Quotes erd \end_inset the client. \end_layout \begin_layout Description REQ-16 The API shall provide a facility for convenient stanza (message, presence, info/query) creation, eliminating the risk of illegal stanzas where feasible. \end_layout \begin_layout Description REQ-17 The API shall allow for convenient construction of JabberIDs. \end_layout \begin_layout Description REQ-18 The API shall provide utility functions to check whether or not a JID is full or bare. \end_layout \begin_layout Description REQ-19 The API shall provide conversion functions to convert from a string to ( \begin_inset Quotes eld \end_inset Maybe \begin_inset Quotes erd \end_inset ) JID, and JID to string. \end_layout \begin_layout Description REQ-20 The API shall provide an optional way for clients to receive time-out events on requests made, such as an IQ or connection attempt. The time-out interval should be customizable. \end_layout \begin_layout Description REQ-21 The library should generate an internal infinite list of unique stanza IDs; the API should provide a way for application developers to acquire any amount of such IDs \end_layout \begin_layout Description REQ-22 The system must offer timeout callbacks to be called if an asynchronous result is not guaranteed to be produced in a timely fashion. \end_layout \begin_layout Description REQ-23 The system must a convenient API to deal with stanza and stream errors. \end_layout \begin_layout Subsection Performance requirements \end_layout \begin_layout Standard There is only one XMPP client per instance of the system. \end_layout \begin_layout Description REQ-24 Regular desktop computers should be able to run hundreds of Pontarius XMPP 0.1 clients. \end_layout \begin_layout Description REQ-25 Pontarius XMPP 0.1 should support virtually as many stanzas per second as (non-throttled) XMPP servers are able to route. This goes for both lightweight, heavy and mixed stanzas. \end_layout \begin_layout Description REQ-26 Processing (parsing, generating, and firing the event) a received stanza should take at most 0.01 seconds. \end_layout \begin_layout Subsection Design constraints \end_layout \begin_layout Subsubsection RFC 6120: XMPP: Core \end_layout \begin_layout Description REQ-27 The system shall support one persistant TCP stream/connection between the XMPP client and the XMPP server. \end_layout \begin_layout Description REQ-28 The system shall implement (at least) the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite for TLS. \end_layout \begin_layout Description REQ-29 The system shall support (at least) the SHA-1 variant of SASL Salted Challenge Response Authentication Mechanism (SCRAM-SHA-1). \end_layout \begin_layout Description REQ-30 XML namespaces for stanzas should always be known to the client. \end_layout \begin_layout Description REQ-31 We must validate incoming XML (though not against the XML schemas). \end_layout \begin_layout Description REQ-32 The system shall always check for the appropriate features before trying to use them. \end_layout \begin_layout Description REQ-33 End-to-end presence or anything else presence-related defined outside of XMPP: Core (such as in XMPP: Instant Messaging) is \emph on not \emph default supported. \end_layout \begin_layout Subsubsection RFC 6122: XMPP: Address Format \end_layout \begin_layout Description REQ-34 JIDs should be validated, transformed, and internationalized in accordanc e with the stringprep profiles Nodeprep, Nameprep, and Resourceprep. \end_layout \begin_layout Description REQ-35 JIDs should be able to use hostnames, IPv4 addresses, and IPv6 addresses, as domainparts. \end_layout \begin_layout Subsubsection Standards compliance \end_layout \begin_layout Description REQ-36 The project and its source code shall adhere to the guidelines prestented in the guidelines found at http://www.haskell.org/haskellwiki/Programming_guideli nes. \end_layout \begin_layout Subsection Software system attributes \end_layout \begin_layout Description REQ-37 The system shall be \emph on extendable \emph default ; it must be flexible in regards for extensions, such as RFCs and XEPs. \end_layout \begin_layout Description REQ-38 The system shall be \emph on reliable \emph default ; it should produce not crash, lag behind, or get some data corruption under very heavy and lengthy use. \end_layout \begin_layout Description REQ-39 The system shall be \emph on secure \emph default ; steps should be taken to protect the clients against man-in-the-middle attacks and the like. \end_layout \end_body \end_document